This invention relates to output device characterization methods and device drivers, and more particularly to a method for characterizing and customizing output printer devices and a driver architecture for use therewith.
The phenomenal growth of the computer industry in both the commercial and consumer market segments has spawned an increasing number of companies who provide both software and peripheral hardware products to the market. It becomes the job of the operating system designer to coordinate and ensure compatibility of data flow within, between, and without of the computers on which this software and peripheral hardware is installed. To ensure that the literally thousands of application programs are able to output their data to peripheral printing devices, the operating system designers have developed a graphics device interface (GDI). The GDI affects the output data from the application programs by invoking functions which allow access to printing devices in a device-independent manner. This GDI provides a uniform interface between the literally thousands of application programs and the output peripheral devices to which these programs wish to send data to be printed.
While the GDI provides a uniform interface from the application programs, it is unable to produce actual printer control commands which are capable of driving each of the hundreds of different models of printer devices available on the market. In the past each individual printer 101, 102, . . . 10n required its own individual printer driver 121, 122, . . . 12n as illustrated in FIG. 15. These individual printer drivers 121, 122, . . . 12n, implemented various control functions for their respective printers based upon the standardized output from the graphics device interface 14. These standard functions included initialization, information, output, attribute, mode, and escape. While each of these individual monolithic printer drivers provided the necessary interface to allow proper driving of each individual printer model, they were typically were several megabytes in size. The need for such extensive printer dirvers impacted not only the individual printer manufacturer, but also the individual computer system 16 into which it was to be installed. Specifically, a computer system 16 would require a significant amount of memory dedicated to the storage of individual printer drivers if more then one printer were to be supported by the system 16. This obviously limited the space remaining within the computer system 16 for storage of application programs 18. In addition, because of the complexity of printer drivers, different printer drivers tend to have various quirks (or bugs) that cause great headache for application developers. Consistent, high-quaility printing is a luxury for users. For the same reason, many printer devices do not have drivers for everyOS platoform. For example, many popular consumer printers dondo nott have Windows NT drivers.
For the purpose of easing the development of Windows printer drivers and improving the driver quality across the board, engineers at Microsoft developed a new universal printer driver to be included within the Windows operating system. This new universal printer driver included a standard set of device driver functions based on device characterization which is needed to drive the individual printers. As illustrated in FIG. 16, the computer system 19 implementing the universal driver still utilizes the graphics device interface (GDI) 14 as a means of coordinating the output from the various application programs. The GDI 14 function invokes the device driver functions of a minidriver 171, 172, . . . 17n which correspond to and contain the characterization of individual printer devices 101, 102, . . . 10n.
The difference in this system from that illustrated in FIG. 15 is that the operating system includes the unidriver 15 which includes a standard set of device driver functions required to drive a printing device. In this way, the individual printer manufactures need not provide this coding. In order to actually drive any particular printer device, the unidriver 15 must receive individual printer characterization information from a selected minidriver 171. The universal driver 15 then stores this device characterization data, preferably within a device context, to be used by the device driver functions of the universal driver 15. Other device driver functions of the minidriver 171 forward their invocation to the universal driver 15 by invoking an analogous function of the universal driver 15. In this way, the printer hardware manufacturer needs only supply a relatively small minidriver which contains characterization data for their particular device and which will be used by the unidriver 15 to actually drive the printer. This unidriver/minidriver system is described in U.S. Pat. No. 5,604,843 to Shaw et al. for METHOD AND SYSTEM FOR INTERFACING WITH A COMPUTER OUTPUT DEVICE, the disclosure and teachings of which are incorporated herein by reference.
While this system provides significant advantages over the prior operating system requirement of large monolithic printer drivers, the inability of this universal driver 15 to support continued advances from printer manufacturers, and the difficulty of coding and debugging the required minidriver format has become apparent. Specifically, the architecture of this prior universal printer driver could be likened to a database into which individual printer characterization data from the minidriver must be directly mapped. As such, new features supplied by the printer manufacturers could not be supported by the universal driver because there was nowhere within the universal driver for this new function to be mapped. A new feature could only be implemented if its support were included in a new release of a new version of the universal driver. However, new version releases often lagged quite significantly behind the introduction of new printers having advanced features. As a result of this inability to map new features into the existing universal driver, many original equipment manufacturers (OEMs) reverted to writing their own monolithic printer drivers to allow full support functionality of their new printing devices.
Additionally, the structure of the universal driver required that the minidrivers be of a specific binary format. Since development and coding of these binary minidrivers was difficult at best, Microsoft introduced a graphical user interface (GUI) tool called unitool to aid the software engineer in writing these minidrivers. This unitool driven generic printer characterization (GPC) was intended to provide an application independent way of describing the total functionality and capabilities of one or more printers supplied by a printer OEM. Once this GPC file had been written using the unitool GUI, it was then compiled and linked into a resource DLL. This compiled and linked resource DLL was then installed for use by the universal driver. Unfortunately, if a bug were discovered in the GPC file, the entire process would need to be repeated. This process included accessing the unitool GUI, modifying the binary GPC characterization file, recompiling and relinking this GPC file into the resource DLL, and then reinstalling this compiled and linked resource DLL for use by the unidriver. This significantly impacted the time required for debugging and development of the individual minidrivers.
Because of its rigid architecture, the universal driver provided very limited support for any customization, and that which was provided was only in the areas of command callback, raster dump, filter graphics, and font related callbacks. Additionally, the universal printer driver architecture was neither modular nor extensible further limiting its ability to allow for customized support of new features. This resulted in a master-slave relationship between the universal driver and the minidriver, constraining the support and functionality to its implemented structure and supported features. This resulted in a great deal of consternation within the printer OEM community.
The universal printer driver (Unidrv5) of the instant invention is a new 32-bit universal printer driver developed by Microsoft for initial implementation in Windows NT5.0. Compared to previous versions of a universal printer driver in various Windows operating systems (OS), the Unidrv5 of the instant invention is designed to dramatically improve the extensibility of the driver architecture and the support for printer features. A key new feature of the instant invention includes a new printer data description format called Generic Printer Description (GPD). Compared to GPC/UNITOOL described above, GPD offers much improved capability to describe printer devices. The architecture of Unidrv5 also supports extensive original equipment manufacturer (OEM) customization interface. This extensibility allows OEM""s to plug in special code for customizing the UI, bitmap handling, font and text processing, and general printer control.
The Unidrv5 of the instant invention utilizes a flexible modular architecture which allows enhancements to the driver to be implemented to provide better support for more varieties of output devices, and to improve the output quality, ease of use and performance without the necessity for redesign. Examples include the support for a generic font installer interface, limited vector printing capability, using page content analysis to improve printing quality and performance, and offering more flexibility in UI customization including complete UI functionality replacement.
Generic Printer Description (GPD) is a new text-based printer description file format for creating minidrivers that run with the Unidrv5 of the instant invention. In a preferred embodiment of the instant invention, there is one GPD file for each printer model. But different printers can share GPD data by using the *Include capability in GPD. A GPD file describes all the features on a printer and how to display and invoke these features. It also contains printer-specific commands and attributes that enable the Unidrv5 to generate the correct printer-ready output data. Compared to the binary-based GPC file format used by previous versions of UNIDRV, GPD offers several key advantages.
First, GPD provides support for generic features. This allows adding support for new printer features (such as Print Density, Stapling, etc.) without any change to the Unidrv5. Second, GPD also provides support for custom help. A printer vendor can specify a custom help file to augment the default help file, which would provide users specific context-sensitive help for generic features and other features. Third, GPD provides support for installable options. This allows minidriver developers to specify which printer options are installable. The driver UI asks the user which options are actually installed and allow users to select only those that are installed. Fourth, GPD provides support for various types of constraints. This allows minidriver developers to specify constraints between option selections, such as xe2x80x9cthe combination of 720 dpi, plain paper and color printing is an invalid configurationxe2x80x9d, or constraints between option installations, or constraints between option installation and option selection.
Additionally, GPD provides support for value dependency. This generic mechanism gives minidriver developers great power to describe any kind of dependency between printer commands and/or attributes. Combined with the new command parameter specification scheme, it significantly reduces the need to write command callback code. Further, GPD provides a new command parameter specification scheme. In GPC, each printing command (ex. x-move-to) has a pre-defined list of parameters and there are only limited ways (as supported in EXTCD structure) to manipulate the actual parameter values. GPD, however, allows each command to pick any parameters from a pool of standard variables (essentially a partial snapshot of the printer and driver state that the Unidrv5 maintains). GPD also supports arbitrary arithmetic manipulation of these parameters. Additionally, GPD provides great extensibility. It is very easy to add new features, printer commands or attributes to the GPD file without any impact on Unidrv5. The GPD parser parses the data into a single binary format and Unidrv5 never needs to worry about different binary formats, as was the case with GPC revisions.
The driver user interface (UI) of the Unidrv5 utilizes a similar tree view UI as used by Windows NT4.0 printer drivers, as shown in FIG. 7. Standard Properties are included on the layout and paper/quality property sheets illustrated in FIG. 8.
The driver UI, implemented as the user-mode DRIVERUI.DLL, displays all printer features specified in GPD, whether they are standard or generic. For generic features, they are displayed in the order listed in the GPD file generally. The driver UI also enforces the constraints specified in the GPD file. It checks on installable options and allow users to select only those options that are actually installed.
The Unidrv5 of the instant invention preferably is titled UNIDRV.DLL. It handles all DDI calls and generates printer-specific output data based on information in the given GPD file. Unidrv5 also handles raster printing. Unidrv5 supports a large set of printer raster data formats. This includes all types of dot-matrix printers, serial ink jet printers, and page printers. Both monochrome and color printing are supported. In fact, the minidriver developer can define multiple color printing modes in GPD, for example, one with driver rendering in 4 bpp format and another in 24 bpp format. Unidrv5 performs the necessary data conversion and/or halftone to generate raster data ready for the printer. The GPD file can specify what is the default printing mode. It could even suppress the monochrome mode if desired. Unidrv5 also provides color matching support by using ICM2.0 on the host machine. Printer vendors can provide ICC color profiles for their printers and make the association via the printer""s .INF file.
Unidrv5 supports device-resident fonts, font cartridges, host-based bitmap fonts, and host-based TrueType fonts. Unidrv5 has built-in support for incremental downloading of TrueType fonts as PCL soft fonts (bitmap and maybe outline). It also supports OEM plug-in""s to download TrueType fonts in other printer-specific formats. Unidrv5 also supports FE fonts and wide device fonts (i.e. fonts with more than 256 glyphs). It also supports font substitution (substituting device fonts for system TrueType fonts for better performance).
In the render mode, OEM""s can write a plug-in module to extend the capability of Unidrv5 in the various areas. First, an OEM can extend the capability of Unidrv5 in the area of raster data processing. Unidrv5 allows OEM""s to hook out raster processing at two levels: at the band level where Unidrv5 would pass a whole band of data; or at the scanline level where Unidrv5 would pass a buffer of raster data for feeding one print head pass. OEM""s can also define custom halftone patterns (up to 256xc3x97256 size) in the GPD file. Unidrv5 passes the information of the currently selected halftone pattern to GDI which uses it instead of a standard system halftone pattern. Second, an OEM can extend the capability of Unidrv5 in the area of font downloading. Unidrv5 supports an extensible font downloading interface to allow minidrivers to support non-PCL formats. Additionally, an OEM can extend the capability of Unidrv5 in the area of command callbacks. For any GPD command, the minidriver can specify a callback id in order to gain control at the point of emitting that particular command. This essentially gives minidrivers an extensive set of injection points where they can influence the output data stream dynamically. OEM""s can also hook out any DDI function for state checking and information caching.
Unidrv5 color support has many improvements compared to previous drivers. First, Unidrv5 adds support for dithered text and allows the driver to query the original brush color at DrvTextOut time. This enables Unidrv5 to achieve WYSIWYG effect on text colors, resulting in better text quality. Unidrv5 also has improved halftone support by improving the standard set of halftone patterns for better output. quality. Unidrv5 also adds support for custom halftone patterns provided by the printer driver. Additionally, Unidrv5 also supports custom image processing. Unidrv5 allows OEM""s to plug in special code for optimized halftone and/or color correction at the backend. Unidrv5 supports ICM2.0 for better color output quality.